Säkra kommunikation mellan olika ursprung: Bästa praxis för JavaScript PostMessage

I dagens moderna webbekosystem behöver applikationer ofta kommunicera mellan olika ursprung. Detta är särskilt vanligt vid användning av iframes, web workers eller vid interaktion med tredjepartsskript. JavaScripts window.postMessage()-API erbjuder en kraftfull och standardiserad mekanism för att uppnå detta. Men som med alla kraftfulla verktyg medför det inneboende säkerhetsrisker om det inte implementeras korrekt. Denna omfattande guide går på djupet med säkerheten för kommunikation mellan olika ursprung med postMessage och erbjuder bästa praxis för att skydda dina webbapplikationer mot potentiella sårbarheter.

Förståelse för kommunikation mellan olika ursprung och Same-Origin Policy

Innan vi dyker in i postMessage är det avgörande att förstå konceptet med ursprung och Same-Origin Policy (SOP). Ett ursprung definieras av kombinationen av ett schema (t.ex. http, https), ett värdnamn (t.ex. www.example.com) och en port (t.ex. 80, 443).

SOP är en grundläggande säkerhetsmekanism som upprätthålls av webbläsare. Den begränsar hur ett dokument eller skript som laddats från ett ursprung kan interagera med resurser från ett annat ursprung. Till exempel kan ett skript på https://example.com inte direkt läsa DOM för en iframe som laddats från https://another-domain.com. Denna policy förhindrar skadliga webbplatser från att stjäla känslig data från andra webbplatser som en användare kan vara inloggad på.

Det finns dock legitima scenarier där kommunikation mellan olika ursprung är nödvändig. Det är här window.postMessage() briljerar. Det tillåter skript som körs i olika webbläsarkontexter (t.ex. ett överordnat fönster och en iframe, eller två separata fönster) att utbyta meddelanden på ett kontrollerat sätt, även om de har olika ursprung.

Hur window.postMessage() fungerar

window.postMessage()-metoden gör det möjligt för ett skript på ett ursprung att skicka ett meddelande till ett skript på ett annat ursprung. Den grundläggande syntaxen är som följer:

            otherWindow.postMessage(message, targetOrigin, transfer);

            

              
                Copy
              
            
          

• otherWindow: En referens till det fönsterobjekt som meddelandet ska skickas till. Detta kan vara en iframes contentWindow eller ett fönster som erhållits via window.open().
• message: Datan som ska skickas. Detta kan vara vilket värde som helst som kan serialiseras med den strukturerade kloningsalgoritmen (strängar, nummer, booleans, arrayer, objekt, ArrayBuffer, etc.).
• targetOrigin: En sträng som representerar det ursprung som det mottagande fönstret måste matcha. Detta är en avgörande säkerhetsparameter. Om den är inställd på "*" kommer meddelandet att skickas till vilket ursprung som helst, vilket generellt sett är osäkert. Om den är inställd på "/" betyder det att meddelandet kommer att skickas till vilken underordnad ram som helst som är på samma domän.
• transfer (valfri): En array av Transferable-objekt (som ArrayBuffers) som kommer att överföras, inte kopieras, till det andra fönstret. Detta kan förbättra prestandan för stora datamängder.

På den mottagande sidan hanteras ett meddelande via en händelselyssnare:

            window.addEventListener("message", receiveMessage, false);

function receiveMessage(event) {
  // ... bearbeta det mottagna meddelandet ...
}

            

              
                Copy
              
            
          

event-objektet som skickas till lyssnaren har flera viktiga egenskaper:

• event.origin: Ursprunget för fönstret som skickade meddelandet.
• event.source: En referens till fönstret som skickade meddelandet.
• event.data: Den faktiska meddelandedatan som skickades.

Säkerhetsrisker associerade med window.postMessage()

Den primära säkerhetsrisken med postMessage uppstår från potentialen för skadliga aktörer att avlyssna eller manipulera meddelanden, eller att lura en legitim applikation att skicka känslig data till ett opålitligt ursprung. De två vanligaste sårbarheterna är:

1. Brist på ursprungsvalidering (Man-in-the-Middle-attacker)

Om targetOrigin-parametern är inställd på "*" när ett meddelande skickas, eller om det mottagande skriptet inte validerar event.origin korrekt, kan en angripare potentiellt:

• Avlyssna känslig data: Om din applikation skickar känslig information (som sessionstokens, användaruppgifter eller PII) till en iframe som förväntas komma från en betrodd domän men som i själva verket kontrolleras av en angripare, kan den datan läckas.
• Utföra godtyckliga åtgärder: En skadlig sida kan efterlikna ett betrott ursprung och ta emot meddelanden avsedda för din applikation, för att sedan utnyttja dessa meddelanden för att utföra åtgärder på uppdrag av användaren utan deras vetskap.

2. Hantering av opålitlig data

Även om ursprunget valideras kommer data som tas emot via postMessage från en annan kontext och bör behandlas som opålitlig. Om det mottagande skriptet inte sanerar eller validerar den inkommande event.data kan det vara sårbart för:

• Cross-Site Scripting (XSS)-attacker: Om den mottagna datan injiceras direkt i DOM eller används på ett sätt som tillåter exekvering av godtycklig kod (t.ex. `innerHTML = event.data`), kan en angripare injicera skadliga skript.
• Logiska fel: Felformaterad eller oväntad data kan leda till logiska fel i applikationen, vilket potentiellt kan orsaka oavsiktligt beteende eller säkerhetshål.

Bästa praxis för säker kommunikation mellan olika ursprung med postMessage()

Att implementera postMessage på ett säkert sätt kräver en djupgående försvarsstrategi. Här är de väsentliga bästa metoderna:

1. Ange alltid ett `targetOrigin`

Detta är utan tvekan den mest kritiska säkerhetsåtgärden. Använd aldrig "*" för targetOrigin i produktionsmiljöer om du inte har ett extremt specifikt och välförstått användningsfall, vilket är sällsynt.

Istället: Ange explicit det förväntade ursprunget för det mottagande fönstret.

            // Skickar ett meddelande från förälder till en iframe
const iframe = document.getElementById('myIframe');
const targetDomain = 'https://trusted-iframe-domain.com'; // Det förväntade ursprunget för iframen

iframe.contentWindow.postMessage('Hej från förälder!', targetDomain);

            

              
                Copy
              
            
          

Om du är osäker på det exakta ursprunget (t.ex. om det kan vara en av flera betrodda underdomäner), kan du kontrollera det manuellt eller använda en mer avslappnad, men fortfarande specifik, kontroll. Att hålla sig till det exakta ursprunget är dock det säkraste.

2. Validera alltid `event.origin` på mottagarsidan

Avsändaren anger den avsedda mottagarens ursprung med targetOrigin, men mottagaren måste verifiera att meddelandet faktiskt kom från det förväntade ursprunget. Detta skyddar mot scenarier där en skadlig sida kan lura din iframe att tro att den är en legitim avsändare.

            window.addEventListener('message', function(event) {
  const expectedOrigin = 'https://trusted-parent-domain.com'; // Det förväntade ursprunget för avsändaren

  // Kontrollera om ursprunget är vad du förväntar dig
  if (event.origin !== expectedOrigin) {
    console.error('Meddelande mottaget från oväntat ursprung:', event.origin);
    return; // Ignorera meddelande från opålitligt ursprung
  }

  // Nu kan du säkert bearbeta event.data
  console.log('Meddelande mottaget:', event.data);

}, false);

            

              
                Copy
              
            
          

Internationella överväganden: När man hanterar internationella applikationer kan ursprung inkludera landsspecifika domäner (t.ex. .co.uk, .de, .jp). Se till att din ursprungsvalidering korrekt hanterar alla förväntade internationella variationer.

3. Sanera och validera `event.data`

Behandla all inkommande data från postMessage som opålitlig användarinmatning. Använd aldrig event.data direkt i känsliga operationer eller rendera den direkt i DOM utan korrekt sanering och validering.

Exempel: Förhindra XSS genom att validera datatyp och struktur

            window.addEventListener('message', function(event) {
  const expectedOrigin = 'https://trusted-sender.com';
  if (event.origin !== expectedOrigin) {
    return;
  }

  const messageData = event.data;

  // Exempel: Om du förväntar dig ett objekt med 'command' och 'payload'
  if (typeof messageData === 'object' && messageData !== null && messageData.command) {
    switch (messageData.command) {
      case 'updateUserPreferences':
        // Validera payload innan du använder den
        if (messageData.payload && typeof messageData.payload.theme === 'string') {
          // Uppdatera inställningar säkert
          applyTheme(messageData.payload.theme);
        }
        break;
      case 'logMessage':
        // Sanera innehåll innan visning
        const cleanMessage = DOMPurify.sanitize(messageData.content);
        displayLog(cleanMessage);
        break;
      default:
        console.warn('Okänt kommando mottaget:', messageData.command);
    }
  } else {
    console.warn('Mottog felformaterad meddelandedata:', messageData);
  }

}, false);

function applyTheme(theme) {
  // ... logik för att applicera tema ...
}

function displayLog(message) {
  // ... logik för att säkert visa meddelande ...
}

            

              
                Copy
              
            
          

Saneringsbibliotek: För HTML-sanering, överväg att använda bibliotek som DOMPurify. För andra datatyper, implementera strikt validering baserad på förväntade format och begränsningar.

4. Var specifik med meddelandeformatet

Definiera ett tydligt kontrakt för de meddelanden som utbyts. Detta inkluderar strukturen, förväntade datatyper och giltiga värden för meddelandets innehåll. Detta gör valideringen enklare och minskar attackytan.

Exempel: Använda JSON för strukturerade meddelanden

            // Skickar
const message = {
  type: 'USER_ACTION',
  payload: {
    action: 'saveSettings',
    settings: {
      language: 'en-US',
      notifications: true
    }
  }
};

window.parent.postMessage(JSON.stringify(message), 'https://trusted-app.com');

// Mottar
window.addEventListener('message', (event) => {
  if (event.origin !== 'https://trusted-app.com') return;

  try {
    const data = JSON.parse(event.data);

    if (data.type === 'USER_ACTION' && data.payload && data.payload.action === 'saveSettings') {
      // Validera data.payload.settings struktur och värden
      if (validateSettings(data.payload.settings)) {
        saveSettings(data.payload.settings);
      }
    }
  } catch (e) {
    console.error('Misslyckades med att tolka meddelande eller ogiltigt meddelandeformat:', e);
  }
});

            

              
                Copy
              
            
          

5. Var försiktig med `window.opener` och `window.top`

Om din sida öppnas av en annan sida med window.open(), har den tillgång till window.opener. På samma sätt har en iframe tillgång till window.top. En skadlig överordnad sida eller ram på toppnivå kan potentiellt utnyttja dessa referenser.

• Från barnets/iframens perspektiv: När du skickar meddelanden uppåt (till det överordnade fönstret eller toppfönstret), kontrollera alltid om window.opener eller window.top existerar och är tillgängligt innan du försöker skicka ett meddelande.
• Från det överordnade/toppfönstrets perspektiv: Var medveten om vilken information du tar emot från underordnade fönster eller iframes.

Exempel (barn till förälder):

            // I ett barnfönster öppnat med window.open()
if (window.opener) {
  const trustedOrigin = 'https://parent-domain.com'; // Förväntat ursprung för öppnaren
  window.opener.postMessage('Hej från barn!', trustedOrigin);
}

            

              
                Copy
              
            
          

6. Förstå och mildra risker med `window.open()` och tredjepartsskript

När du använder window.open() kan det returnerade fönsterobjektet användas för att skicka meddelanden. Om du öppnar en tredjeparts-URL måste du vara extremt försiktig med vilken data du skickar och hur du hanterar svar. Omvänt, om din applikation är inbäddad eller öppnad av en tredje part, se till att din ursprungsvalidering är robust.

Exempel: Öppna en betalningsgateway i ett popup-fönster

Ett vanligt mönster är att öppna en betalningssida i ett popup-fönster. Det överordnade fönstret skickar betalningsuppgifter (säkert, vanligtvis inte känslig PII direkt utan kanske ett order-ID) och förväntar sig ett bekräftelsemeddelande tillbaka.

            // Överordnat fönster
const paymentWindow = window.open('https://payment-provider.com/checkout', 'PaymentWindow', 'width=600,height=800');

// Skicka orderdetaljer (t.ex. order-ID, belopp) till betalningsfönstret
paymentWindow.postMessage({
  orderId: '12345',
  amount: 100.50,
  currency: 'USD'
}, 'https://payment-provider.com');

// Lyssna efter bekräftelse
window.addEventListener('message', (event) => {
  if (event.origin === 'https://payment-provider.com') {
    if (event.data && event.data.status === 'success') {
      console.log('Betalning lyckades!');
      // Uppdatera UI, markera order som betald
    } else if (event.data && event.data.status === 'failed') {
      console.error('Betalning misslyckades:', event.data.message);
    }
  }
});

// I payment-provider.com (inom sitt eget ursprung)
window.addEventListener('message', (event) => {
  // Ingen ursprungskontroll behövs här för att *skicka* till föräldern, eftersom det är en kontrollerad interaktion
  // MEN för att ta emot, skulle föräldern kontrollera betalningsfönstrets ursprung.
  // Låt oss anta att betalningssidan vet att den kommunicerar med sin egen förälder.

  if (event.data && event.data.orderId === '12345') { // Grundläggande kontroll
    // Bearbeta betalningslogik...
    const paymentSuccess = performPayment();

    if (paymentSuccess) {
      event.source.postMessage({ status: 'success' }, event.origin); // Skickar tillbaka till föräldern
    } else {
      event.source.postMessage({ status: 'failed', message: 'Transaktionen nekades' }, event.origin);
    }
  }
});

            

              
                Copy
              
            
          

Viktig lärdom: Var alltid explicit med ursprung när du skickar till potentiellt okända fönster eller tredjepartsfönster. För svar anges källfönstrets ursprung, vilket mottagaren sedan måste validera.

7. Använd händelselyssnare ansvarsfullt

Se till att händelselyssnare för meddelanden kopplas på och tas bort på lämpligt sätt. Om en komponent avmonteras bör dess händelselyssnare rensas upp för att förhindra minnesläckor och potentiellt oavsiktlig meddelandehantering.

            // Exempel i ett ramverk som React

function MyComponent() {
  const handleMessage = (event) => {
    // ... bearbeta meddelande ...
  };

  useEffect(() => {
    window.addEventListener('message', handleMessage);
    // Uppstädningsfunktion för att ta bort lyssnaren när komponenten avmonteras
    return () => {
      window.removeEventListener('message', handleMessage);
    };
  }, []); // Tom beroendearray betyder att detta körs en gång vid montering och en gång vid avmontering

  // ... resten av komponenten ...
}

            

              
                Copy
              
            
          

8. Minimera dataöverföring

Skicka endast den data som är absolut nödvändig. Att skicka stora mängder data ökar risken för avlyssning och kan påverka prestandan. Om du behöver överföra stora binära data, överväg att använda transfer-argumentet i postMessage med ArrayBuffers för prestandafördelar och för att undvika datakopiering.

9. Utnyttja Web Workers för komplexa uppgifter

För beräkningsintensiva uppgifter eller scenarier som involverar betydande databearbetning, överväg att avlasta detta arbete till Web Workers. Workers kommunicerar med huvudtråden med postMessage, och de körs i ett separat globalt scope, vilket ibland kan förenkla säkerhetsöverväganden inom workern själv (även om kommunikationen mellan workern och huvudtråden fortfarande måste säkras).

10. Dokumentation och granskning

Dokumentera alla kommunikationspunkter mellan olika ursprung i din applikation. Granska regelbundet din kod för att säkerställa att postMessage används på ett säkert sätt, särskilt efter ändringar i applikationsarkitekturen eller integrationer med tredje part.

Vanliga fallgropar och hur man undviker dem

• Använda "*" för targetOrigin: Som betonats tidigare är detta ett betydande säkerhetshål. Ange alltid ett ursprung.
• Att inte validera event.origin: Att lita på avsändarens ursprung utan verifiering är farligt. Kontrollera alltid event.origin.
• Använda event.data direkt: Bädda aldrig in rådata direkt i HTML eller använd den i känsliga operationer utan sanering och validering.
• Ignorera fel: Felformaterade meddelanden eller tolkningsfel kan tyda på skadlig avsikt eller helt enkelt buggiga integrationer. Hantera dem elegant och logga dem för utredning.
• Anta att alla ramar är betrodda: Även om du kontrollerar en överordnad sida och en iframe, om den iframen laddar innehåll från en tredje part, blir den en sårbarhetspunkt.

Överväganden för internationella applikationer

När man bygger applikationer som betjänar en global publik kan kommunikation mellan olika ursprung involvera domäner med olika landskoder eller underdomäner som är specifika för regioner. Det är avgörande att se till att dina kontroller av targetOrigin och event.origin är tillräckligt omfattande för att täcka alla legitima ursprung.

Till exempel, om ditt företag verkar i flera europeiska länder kan dina betrodda ursprung se ut så här:

• https://www.example.com (global webbplats)
• https://www.example.co.uk (brittisk webbplats)
• https://www.example.de (tysk webbplats)
• https://blog.example.com (blogg-underdomän)

Din valideringslogik måste kunna hantera dessa variationer. Ett vanligt tillvägagångssätt är att kontrollera värdnamnet och schemat, och säkerställa att det matchar en fördefinierad lista över betrodda domäner eller följer ett specifikt mönster.

            function isValidOrigin(origin) {
  const trustedDomains = [
    'https://www.example.com',
    'https://www.example.co.uk',
    'https://www.example.de'
  ];
  return trustedDomains.includes(origin);
}

window.addEventListener('message', (event) => {
  if (!isValidOrigin(event.origin)) {
    console.error('Meddelande från opålitligt ursprung:', event.origin);
    return;
  }
  // ... bearbeta meddelande ...
});

            

              
                Copy
              
            
          

När du kommunicerar med externa, opålitliga tjänster (t.ex. ett tredjepartsanalysskript eller en betalningsgateway), följ alltid de strängaste säkerhetsåtgärderna: specifik targetOrigin och rigorös validering av all data som tas emot tillbaka.

Slutsats

JavaScripts window.postMessage()-API är ett oumbärligt verktyg för modern webbutveckling som möjliggör säker och flexibel kommunikation mellan olika ursprung. Dess kraft kräver dock en stark förståelse för dess säkerhetsimplikationer. Genom att noggrant följa bästa praxis – specifikt att alltid ange ett exakt targetOrigin, rigoröst validera event.origin och grundligt sanera event.data – kan utvecklare bygga robusta applikationer som kommunicerar säkert mellan ursprung, skyddar användardata och upprätthåller applikationens integritet i dagens uppkopplade webb.

Kom ihåg att säkerhet är en pågående process. Granska och uppdatera regelbundet dina strategier för kommunikation mellan olika ursprung i takt med att nya hot uppstår och webbteknologier utvecklas.